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Abstract 

The  objective  for  Global  Force  Management  (GFM)  is  to  establish  a  transparent  and  universal 
process  to  manage,  assess  and  display  the  worldwide  disposition  of  US  forces.  This  includes  US 
force  availability,  readiness  and  capability  in  order  to  assess  the  risks  associated  with  proposed 
allocation,  assignment  and  apportionment  options.  Fundamental  to  GFM  and  foundational  to 
transformation  is  the  GFM  Data  Initiative  (GFM  DI),  which  addresses  organizing  force  structure 
data  in  a  joint  hierarchal  way  for  integration  across  Service  lines.  To  address  the  GFM  data 
problem,  provide  the  data  in  network  centric  environment,  and  manage  the  data,  a  Community  of 
Interest  (COI),  as  described  in  the  Net  Centric  Data  Strategyl  (NCDS)1 2,  was  established  in  the 
summer  of  2003.  The  GFM  COI  is  co-chaired  by  the  Joint  Staff,  Force  Structure,  Resources,  and 
Assessment  Directorate  (J-8)  and  the  Office  of  the  Under-Secretary  of  Defense  for  Personnel  and 
Readiness  (USD(P&R)).3  The  GFM  COI  is  a  governing  body  now  implementing  a  set  of 
organization  servers,  maintained  by  OSD,  the  Services,  and  the  Joint  community,  that  will  provide 
high  resolution,  default  force  structure  data  for  a  diverse  set  of  users.  This  paper  describes  some  of 
the  challenges  encountered  during  the  establishment,  evolution,  and  first  18  months  of  operation 
of  a  COI.  Not  surprisingly,  a  COI  is  not  a  magical  solution  and  it  does  not  displace  the  difficult 
task  and  extensive  intellectual  efforts  required  to  establish  agreements  among  diverse  users  of 
data,  even  when  the  data  set  is  restricted. 


1  From  the  Department  of  Defense  Net-Centric  Data  Strategy,  9  May  2003;  see: 

http://www.defenselink.mil/nii/org/cio/doc/Net-Centric-Data-Strategy-2003-05-092.pdf 

2  See:  http://www.dtic.mil/ics/core/i8.html 

3  See:  http://www.dod.mil/prhome/readiness.html 
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1.  A  Community  of  Interest  (COI)  Should  Be  Created  To  Solve  A  Problem 

In  January  2003,  the  Department  of  Defense  began  development  of  the  force  structure  lay-down 
for  the  second  rotation  of  forces  to  deploy  to  Iraq.  This  process,  known  as  the  allocation  of  forces, 
is  the  Secretary  of  Defense’s  responsibility  and  is  based  upon  recommendations  submitted  by  the 
joint  force  provider  that  are  reviewed  by  the  Joint  Chiefs  of  Staff  (JCS).  In  this  process,  the 
world-wide  disposition  of  forces  is  examined  and  assessed  to  determine  the  recommended  force 
rotation  based  on  a  number  of  factors  including  (but  not  limited  to)  current  force  locations,  what 
their  past  employment  has  been,  their  current  readiness  status,  and  the  requirements  for  all 
Combatant  Commanders’  plans. 

The  information  requirements  for  this  process  are  significant  and  demanding.  The  process 
requires  detailed  data  on  current  information,  future  commitments,  potential  capabilities  of  all 
forces,  and  the  ability  to  assess  the  risk  to  all  existing  plans  and  commitments.  Difficulties  in 
developing  a  recommendation  include:  the  processes  of  pulling  data  from  multiple  Service 
specific  (and  some  joint)  systems,  augmenting  the  data  via  significant  manual,  labor-intensive 
intervention  to  reconcile  inconsistencies,  and  then  applying  planner  judgment  and  expertise  to 
resolve  the  numerous  data  discrepancies.  Today,  this  process  cannot  be  accomplished  with  a  fine 
degree  of  precision  in  a  timely  manner,  thus  requiring  multiple  reviews  and  significant  planner 
coordination.  In  fact,  only  combat  force  elements  and  select  enablers  are  tracked. 

In  addition  to  the  major  combat  units,  OEF/OIF4  required  specific  capabilities  supplemented 
within  the  theater.  Many  of  these  capabilities  were  met  by  sourcing  only  partial  units  to  meet  the 
requirement.  As  these  additional  capabilities  were  added,  the  tracking  of  decomposed  unit  level 
organizations  throughout  the  process  became  unmanageable.  Moreover,  determining  residual 
capability  and  tracking  of  remaining  partial  units  was  problematic.  A  new  approach  had  to  be 
developed  to  be  able  to  handle  this  process,  as  exiting  systems  did  not  support  tracking  of 
decomposed  units.  Moreover,  linkage  to  combat  support  (CS)  and  combat  service  support  (CSS) 
units  were  only  fully  considered  after  decisions  had  been  made  on  the  combat  units. 

In  an  effort  to  perform  this  function,  the  J-8  developed  an  automated  tool  to  assist  in  the  process. 
Using  only  major  combat  formations,  the  tool  laid  out  forces  allocated  to  OEF/OIF,  the  future 
OEF/OIF  allocation,  and  residual  capabilities  for  apportionment  for  other  Combatant 
Commanders’  contingency  planning.  Although  most  of  this  information  is  available  somewhere, 
it  cannot  be  easily  discovered  or  accessed  in  a  timely  manner,  and  does  not  render  itself  for  easy 
manipulation  by  computers.  The  tool  is  helpful,  but  does  not  resolve  the  underlying  data 
concerns. 

The  requirements  for  this  new  process  were  fairly  straightforward.  It  must  be  able  to  handle  any 
task-organized  force  (based  upon  the  capabilities  desired),  include  the  entire  US  force  structure 
inventory  (as  contrasted  to  just  the  major  combat  organizations),  be  able  to  show  the  current  and 
future  operational  availability,  and  have  the  data  organized  and  accessible  within  the  joint 
community.  Simultaneously,  the  joint  community  also  wanted  to  be  able  to  track  forces  once  they 


4  OEF:  Operation  Enduring  Freedom;  OIF:  Operation  Iraqi  Freedom. 
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were  deployed,  accounting  for  both  the  location  of  these  forces  and  the  “activities/events”  these 
forces  were  performing. 

As  the  J-8  worked  on  the  Assignment,  Allocation,  and  Apportionment  process,  the  first  problem 
was  to  identify  what  data  exists  to  facilitate  answering  these  questions.  The  initial  data  store  used 
was  the  data  collected  for  the  Force  Structure  Screening  Tool  (FSST).  Three  major  problems  were 
discovered  when  attempting  to  use  the  FSST  for  real  operational/actual  data: 

■  Data  latency.  Although  the  data  may  have  been  available,  it  was  not  kept  current. 

■  Level  of  Detail.  Most  of  the  data  collected  only  went  to  the  Unit  Identification  Code 
(UIC)  level  of  detail.  The  current  deployment  schedule  demanded  a  level  of  detail  well 
below  that  of  UIC. 

■  Lack  of  a  Standard  Terminology.  Each  of  the  Services  presented  their  data  differently. 
For  example,  when  comparing  a  USMC  battalion  to  a  US  Army  battalion,  there  were  no 
common  representations  between  the  two  elements.  Common  factors  that  everyone 
understood  had  to  be  developed,  so  that  one  could  compare  the  two  units  (e.g.,  “boots  on 
the  ground”  to  account  for  the  number  of  people  that  were  actually  deployed/deploying). 

The  problem  that  had  to  be  solved  was  the  collection  of  information  necessary  to  make  an 
informed  decision  for  the  future  OIF/OEF  rotations.  It  was  decided,  at  the  very  highest  levels,  to 
use  the  venerable  “brute  force”  method  to  create  the  global  force  laydown  for  OIF/OEF. 

■  Information  requirements  were  developed  for  an  Excel  spreadsheet  called  the  “Global 
Force  Laydown”  (GFL). 

■  The  real  “operational”  data,  as  reported  by  the  Services,  was  the  initial  source  for 
populating  the  GFL.  This  operational  data  was  used  to  populate  some,  but  not  all,  of  the 
data  requirements  for  the  GFL. 

■  A  special  data  call  went  to  the  Services  requesting  an  update  to  this  information  for  all 
major  combat  units.  Notice  that  “major  combat  units”  specifically  excludes  all  CS  and 
CSS  units  that  are  considered  later  in  the  process.  A  standardized  format  (in  an  Excel 
spreadsheet)  was  provided.  A  month  was  required  to  receive  this  information  and 
consolidate  it  into  a  single  list.  Recently,  this  data  request  was  sent  to  Joint  Forces 
Command  rather  than  directly  to  the  Services. 

■  Once  the  list  was  completed,  it  went  to  the  Service  planners  to  verify  that  the  information 
was  still  accurate.  All  Services  continued  to  change,  refine,  or  update  the  information, 
basically  stating  that  changes  to  the  operational  status  were  not  reflected  in  the 
“operational”  data.  Even  after  this  refinement,  it  took  weeks  to  derive  what  really  “was” 
the  current  operational  laydown  (as  of  the  beginning  of  the  month). 

■  The  data  was  “correct,”  but  a  month  out  of  date.  Decisions  were  made  based  on  this 
information.  After  the  decisions  were  finalized  for  the  Combat  units,  CS  and  CSS 
requirements  were  defined  and  sourced  under  a  separate  process. 

■  The  entire  process  took  approximately  five  months  and  several  thousand  man-hours  to 
complete.  A  month  after  completion,  the  entire  process  was  restarted  for  the  next  rotation 
cycle. 


3 


Another  major  problem  was  conflicting  data  requests  that  asked  for  the  same  “type”  of 
information,  but  with  a  slightly  different  flavor  or  format.  Several  requests  for  information  could 
be  made  by  different  offices  within  the  Joint  Staff  Directorate  or  within  the  Joint  Staff  itself,  each 
asking  for  the  data  in  a  slightly  different  way. 

Adding  to  these  problems  was  the  fact  the  data  changed  on  a  daily  basis.  There  was  simply  no 
way  to  keep  the  data  accurate,  current  and  be  able  to  use  it  in  the  decision  making  process. 
Compounding  these  problems  was  the  need  for  High  Density,  Low  Demand  (HDLD)  specialties 
(e.g.,  dog  handling  teams,  prison  guards,  etc.)  that  needed  to  be  manipulated  at  the  individual  level 
rather  than  at  the  UIC  level  of  detail. 

In  May  2003,  the  Department  of  Defense  Net-Centric  Data  Strategy  (NCDS)  was  released  to 
address  the  new  capabilities  created  by  the  Internet  and  Web  Services.  The  intent  of  the  NCDS  is 
to  outline  the  vision  for  managing  data  within  DoD.  The  key  attributes  of  the  strategy  are: 

■  Ensuring  data  are  visible,  available  and  useable  when  needed  and  where  needed  to 
accelerate  decision  making. 

■  “Tagging”  of  all  data  (intelligence,  non- intelligence,  raw,  and  processed)  with  metadata  to 
enable  discovery  of  data  by  users. 

■  Posting  of  all  data  to  shared  spaces  to  provide  access  to  all  users  except  when  limited  by 
security,  policy,  or  regulation. 

■  Advancing  the  Department  from  defining  interoperability  through  point-to-point  interfaces 
to  enabling  the  “many-to-many”  exchanges  typical  of  a  net-centric  data  environment. 

The  Strategy  also  introduces  management  of  data  within  communities  of  interest  (COIs)  rather 
than  standardized  data  elements  across  the  Department.  COI  is  the  inclusive  term  used  to  describe 
collaborative  groups  of  users  who  must  exchange  information  in  pursuit  of  their  shared  goals, 
interests,  missions,  or  business  processes  and  who  therefore  must  have  shared  vocabulary  for  the 
information  they  exchange,  including  any  external  authorized,  but  unanticipated  users.5  With  the 
advent  of  the  NCDS,  it  was  decided  to  try  using  a  COI  to  solve  the  GFM  data  problems. 

2.  The  GFM  DI’s  Scope  Is  Enterprise  Wide,  Making  It  A  Special  Challenge  For  A  COI 

In  2003,  the  Force  Structure,  Resources,  and  Assessment  Directorate  (J-8)  of  the  Joint  Staff, 
sought  resolution  of  these  force  management  issues.  The  desire  to  address  this  issue  began  with 
discussing  the  problem  with  all  of  the  potential  (high-level)  stakeholders  and  gaining  their 
perspectives.  Although  the  primary  impetus  for  creating  the  GFM  COI  was  the  governance  and 
maintenance  of  force  structure  data,  it  soon  became  apparent  that  the  lack  of  consistent  force 
structure  data  affected  every  major  area  within  DoD.  Although  everything  in  DoD  relates  to  force 
structure,  no  single  authoritative  data  source  exists. 


5  From  the  Department  of  Defense  Net-Centric  Data  Strategy,  9  May  2003; 

See:http://www. defenselink.mil/nii/org/cio/doc/Net-Centric-Data-Strategy-2003-05-092.pdf 
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The  “G”  in  GFM  DI  is  real.  Force  structure  data  is  pervasive  across  the  systems  that  comprise  the 
DoD  enterprise,  and  all  the  stakeholders  quickly  recognized  this.  GFM  force  structure  data  was 
needed  for: 


■  The  Defense  Integrated  Military  Human  Resources  Systems  (DIMHRS) 

■  The  Global  Directory  Services 

■  The  Defense  Readiness  Reporting  System 

■  Tying  resources  to  capabilities  and  capabilities  to  force  structure 

■  Unique  Item  Identification  (UID) 

■  Command  and  Control  systems 

■  And  a  host  of  other  automation  systems. 

As  is  indicated  by  this  list,  much  of  the  “GFM  Domain”  (per  NCDS  vernacular)  intersects  a  large 
percentage  of  DoD  data  systems,  thus  making  the  task  of  the  GFM  COI  an  enterprise-wide  task 
which  is  an  anomaly  per  the  intent  of  COIs  in  the  NCES  data  strategy: 

Communities  provide  an  organization  and  maintenance  construct  for  data  such  that  their  data 
goals  are  realized.  Moving  these  responsibilities  to  a  COI  level  reduces  the  coordination  effort 
as  compared  to  managing  every  data  element  Department-wide.6 

As  a  result,  the  GFM  COI  is  being  used  to  address  problems  that  cross  the  Business  Management 
Modernization  Program  (BMMP)  data  domains,  whose  boundaries  are  already  ambiguous.  This 
was  not  an  insignificant  problem.  The  J-8  recognized  that  an  unprecedented  level  of  collaboration 
would  have  to  be  met  to  achieve  a  truly  transformational  evolution  of  data  within  the  Department. 
With  the  publishing  of  the  NCDS,  he  now  had  a  vehicle  to  address  the  force  management  issue. 

To  achieve  high-level  buy-in,  the  J-8  looked  to  several  authoritative  decision  making  bodies  to 
adopt  and  accept  a  force  structure  construct  that  would  transform  how  the  Department  will  use 
data  in  the  future.  The  first  step  was  to  brief  the  force  structure  construct  to  the  Senior  Readiness 
Oversight  Council  (SROC7).  The  SROC  directed  that: 

The  Joint  Staff,  in  coordination  with  USD  (P&R),  will  structure  the  implementation  of 
enterprise-wide  unit  identifiers.  This  initiative  shall  be  consistent  with  Net-Centric  Data 
Strategy,  preclude  redundancy  with  other  identifiers  efforts,  and  synchronize  roadmaps  for 
ongoing  force  management  initiatives.  USD  (P&R)  will  draft  a  DoD  Directive  that  formalizes 
implementation  of  organizational  force  structure  identifiers  across  the  Department.8 

Accomplishing  this  intent  across  DoD  resulted  in  Strategic  Planning  Guidance  (SPG)  language 
creating  the  Global  Force  Management  Data  Initiative  (GFM  DI). 


6  Ibid. 

7  The  SROC  is  comprised  of  the  DepSecDef,  OSD  Primary  staff  members,  Service  Secretaries  and  Chiefs  and  the 
Commandant  of  the  Marine  Corps. 

8  Memorandum  dated  20  Jan  2004,  from  Deputy  Secretary  of  Defense,  Subject:  Actions  from  the  Senior  Readiness 
Oversight  Council  of  December  10,  2003 
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To  support  Global  Force  Management,  the  CJCS  will  develop,  by  31  October  2004,  a  joint 
hierarchical  way  to  organize  force  structure  data  for  integration  across  Service  lines.  The 
Service  Secretaries,  Combatant  Commanders,  D(DISA),  CJCS,  USD(P&R),  and  JPEC  will 
identify  and  develop  common  standards  and  parameters  for  data  semantics,  sources, 
timeliness,  accuracy,  collection,  and  recording  methods  specific  to  force  management.9 

To  keep  the  momentum  going  and  to  ensure  funding  would  be  applied  to  the  GFM  DI,  the 
Initiative  became  an  Enhanced  Planning  Process  (EPP)  Issue.  As  an  EPP  Issue,  the  GFM  DI  was 
briefed  several  times  to  Service  3-Star  Programmers.  Once  all  the  Service  Programmers  accepted 
the  concept,  Joint  Programming  Guidance  (JPG)  language  was  written  that  provided  the  funding 
necessary  for  the  GFM  DI.  The  JPG  directed: 

Global  Force  Management:  Joint  Staff,  Air  Force,  Navy,  Marine  Corps  add  money  during  FY 
2006-2011  from  within  existing  resources  for  development  of  standardized  force  structure  data 
that  will  provide  on-demand  information  in  a  net-centric  environment.10 

3.  COI  Representatives  Fluctuate  As  The  Solution  Evolves 

As  mentioned  previously,  the  “G”  in  “GFM”  really  does  mean  it  is  global.  GFM  DI  crosses  each 
of  the  BMMP  mission  areas  and  domains.  Selecting  the  “right”  COI  membership  was  going  to  be 
a  problem,  as  the  focus  of  the  COI  would  change  over  time.  One  should  not  expect  COI 
membership  to  be  static. 

The  initial  set  of  members  included  representatives  from  the  Military  Services,11  members  of  the 
OSD  primary  staff,  the  Defense  Agencies,  USSOCOM,  and  JFCOM.  The  initial  problem  set 
clearly  rested  in  the  Force  Management  area,  but  the  initial  representatives  did  not  necessarily 
represent  these  communities  within  their  proponents.  After  a  few  adjustments  the  right 
representatives  were  attending  the  meetings. 

COI  meetings  were  initially  held  every  week.  The  main  thrust  of  these  meetings  was  to  get  the 
right  people  there  and  then  educate  them  to  the  problem,  all  the  while  keeping  them  very  narrowly 
focused  on  the  problem  set  that  they  had  to  address  -  namely  making  the  “authoritative”  force 
structure  data  available  in  a  net-environment.  As  part  of  the  education  process,  each  of  the 
members  presented  their  perspectives  on  force  management,  in  an  attempt  to  reach  a  common 
perspective  for  the  Department. 

Workshops  were  held  between  regular  COI  meetings  to  identify  and  cover  technical  issues.  In 
these  workshops,  the  COI  representatives  normally  changed  from  the  “policy”  force  management 
people  to  the  “functional”  people  with  specific  skills  and  expertise.  This  increased  collaboration, 
requiring  more  horizontal  integration  within  the  Department,  was  a  necessary,  although  painfully 
slow,  step.  Significant  coordination  efforts  to  ensure  that  the  correct  representatives  attended  the 
“right”  meetings  were  essential  to  maintain  the  progress  of  the  COI. 


9  Strategic  Planning  Guidance  Fiscal  Years  2006-2011,  15  Mar  2004,  page  30-3 1 

10  Joint  Planning  Guidance  Fiscal  Year  2006-2011,  9  Jun  2004,  page  3 

11  Including  the  Coast  Guard. 
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An  intellectually  difficult  task  of  a  COI  is  determining  the  common  set  of  semantics.  Once  the 
group  agrees  on  what  something  means,  the  entire  process  runs  smoother.  For  example,  if  one 
hears  the  term  “squadron,”  a  certain  type  of  unit  comes  to  mind.  Depending  on  your  experiences, 
one  may  be  thinking  of  a  destroyer  squadron,  an  F-16  squadron,  or  a  cavalry  squadron.  Each  of 
the  proponents  will  contend  that  their  definition  of  a  squadron  is  the  “correct”  one  -  and  it  is,  for 
them.  But  until  a  common  understanding  is  reached  that  all  of  these  terms  are  types  of  “units,” 
progress  cannot  continue. 

Each  of  the  Services  does  force  management  differently  and  rightfully  so,  as  they  perform 
different  functions  within  the  Department.  But,  even  inside  of  the  Services  (supposedly 
“common”),  many  differences  and  inconsistencies  exist.  The  only  thing  that  each  of  the  Services 
really  have  in  common  is  that  they  all  require  flexibility  to  support  the  warfighter.  Guiding  the 
COI  to  a  common  solution  set,  which  by  definition  is  not  the  way  business  is  currently  done,  is 
challenging  and  time  consuming. 

Because  force  structure  is  represented  in  some  way,  shape,  or  fashion  in  every  domain,  the  GFM 
COI  requires  membership  that  spans  every  domain.  The  COI  representatives  must  have  the 
ability  to  span  the  complexity  of  the  solution  set,  going  from  high-level  policy  (and  the  impacts 
upon  the  Department),  to  the  minor,  annoying  technical  details  (which  are  required  to  make  the 
solutions  work.)  Not  only  is  understanding  the  topics  at  several  different  levels  required,  but  one 
must  also  have  meaningful,  “implementable”  agreements.  This  is  due  to  the  fact  that  the  Services 
must  provide  the  majority  of  this  data. 

Over  time,  the  frequency  of  the  COI  meetings  has  diminished,  primarily  because  the  “education” 
phase  takes  significant  time  up-front.  This  was  followed  by  the  “problem  definition”  and  “initial 
solution  set”  phases.  The  GFM  COI  is  now  in  the  “put  real  data  in  and  test  it”  phase.  The 
interesting  observation  of  the  COI  membership  is  that  as  time  goes  on,  attendance  of  the  COI  has 
grown  to  “standing  room  only.”  COI  meetings  are  currently  held  once  a  month,  with  a  robust 
information  package  sent  to  the  membership,  as  the  situation  warrants. 

4.  Vision  Without  Funding  Is  Hallucination  -  the  COI-EPP  Interaction 

The  GFM  DI  is  recognized  as  being  foundational  for  the  transforming  DoD.  It  has  received 
tremendous  momentum  by  being  designated  as  both  an  SPG  Issue  and  one  of  only  eleven  EPP 
Issues.  But  the  bottom  line  is  that  a  vision  without  funding  is  hallucination.  Regardless  of  the 
top-level  interest,  without  funding  this  initiative  would  die  since  no  one  likes  change  and  everyone 
resists  new,  unfiinded  requirements. 

To  ensure  that  it  would  be  pushed  forward  throughout  the  DoD  budgeting  process,  an  EPP  Issue 
Team  was  established  in  parallel  to  the  COI  to  ensure  that  the  results  of  the  COI  were  funded  for 
implementation.  Using  the  Service  points  of  contacts  and  other  key  members  of  the  GFM  COI  as 
its  members,  the  EPP  Issue  Team  was  tasked  to  develop  and  examine  the  funding  needed  for  the 
development  of  standardized  force  structure  data  that  will  provide  on-demand  information  in  a 
net-centric  environment.  The  EPP  Issue  Team  did  just  that,  but  no  new  funding  was  available 
unless  offsets  were  provided.  Most  of  the  details  were  worked  out  within  the  context  of  the  COI, 
and  the  EPP  Issue  Team  briefed  the  results  to  the  Service  3-Star  programmers.  The  Service 
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programmers  agreed  to  add  money  during  FY  2006-2011  from  within  existing  resources  for 
development  of  standardized  force  structure  data,  thus  driving  the  JPG  language. 

5.  A  COI  Requires  a  Set  of  Guiding  Principles  and  Tenets 

It  was  known  early  in  this  process  that  the  GFM  COI  would  drive  new  policies  needed  to  address 
the  integration  to  achieve  the  desired  effects  across  the  DoD.  But  knowing  that  policies  need  to  be 
written  and  figuring  out  what  to  write  are  two  entirely  different  processes. 

The  initial  solution  set  began  with  a  marriage  of  past  force  structure  construct  research,  the 
NCDS,  and  the  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM),  now  known 
as  the  Joint  Consultation,  Command  and  Control  Information  Exchange  Data  Model  (JC3IEDM). 

1  T 

The  JC3IEDM  is  a  collaborative  effort  between  the  Multilateral  Interoperability  Program  (MIP) 
and  the  NATO  Data  Administration  Group  (NDAG);  and  it  provides  a  set  of  information 
elements,  entities,  and  relations  that  describes  the  information  exchange  requirements  within 
tactical  military  operations.  This  solution  set  is  now  known  as  the  GFM  “Force  Structure 
Construct”  (FSC)14,  and  is  described  in  DoD  Directive  8260.3  (Draft,  distribution  pending 
approval). 

The  GFM  FSC  provides  the  framework  and  the  foundation  to  link  authorization  data  together  with 
the  actual  organizations,  equipment,  and  personnel,  as  well  as  other  associated  resource,  readiness, 
and  capability  information  needed  to  answer  the  GFM  DI  questions.  This  will  provide  DoD 
Components  the  ability  to  use  the  organization  structure  for  reporting  data  to  meet  real-time, 
future,  and  unanticipated  requirements  in  a  joint  environment.  The  FSC,  as  developed  by  the 
GFM  COI,  will  be  used  to  represent  all  organizational  structures,  both  administrative  and 
combatant,  within  DoD.  The  FSC  consists  of  three  major  elements:  documenting,  identifying,  and 
disseminating. 

Documenting  the  authorized  force  structure  in  an  authoritative  data  source  using  the  Global  Force 
Management  Information  Exchange  Data  Model  (GFMIEDM)  format  is  the  first  element.  The 
GFMIEDM,  an  augmented  subset  of  the  JC3IEDM,  is  a  reference  model  that  can  be  used  to 
exchange  information  between  two  systems  to  reach  a  common  understanding  of  the  data.  The 
GFMIEDM  contains  the  minimum  essential  set  of  data  elements  that  the  GFM  COI  has 
determined  needs  to  be  exchanged.  Documenting  the  force  structure  includes: 

■  Defining  the  comprehensive,  hierarchal,  default  force  structure  for  use  by  all  systems 
within  the  DoD  enterprise. 


12  Chamberlain,  S.,  Default  Operational  Representations  of  Military  Organizations  for  Joint  and  Coalition 
Operations,  1999  Command  &  Control  Research  &  Technology  Symposium,  Naval  War  College,  Newport,  RI; 
29  Jun-1  Jul  1999;  see:  http://www.dodccrp.org/events/1999/1999CCRTS/pdf  files/track  5/056chamb.pdf. 

13  See:  http://www.mip-site.org. 

14  Chamberlain,  S.  and  Sprung,  G.  A  Unifying  Strategy  for  Data  Integration  for  Global  Force  Management,  9th 
International  Command  and  Control  Research  and  Technology  Symposium,  Copenhagen,  Denmark,  14-16  Sep 
2004;  See:  http://www.dodccrp.org/events/2004/CCRTS  San  Diego/CD/track02.htm. 
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■  Presenting  this  force  structure  data  in  a  “top-to-bottom”  hierarchical  structure,  down  to  the 
billet  level,  and  including  both  the  operational  (doctrine,  tactics,  techniques,  and 
procedures)  and  administrative  (i.e.,  functional  representations)  aspects. 

■  Controlling  and  operating  an  “organization  server.”  An  organization  server  is  the  single 
authoritative  data  source  for  the  authorized  force  structure.  It  is  a  web-enabled  database 
containing  default  operational  organizations  available  via  the  GFMIEDM  format. 

■  The  entire  authorized  force,  to  include  active,  guard,  reserve,  and  civilian  forces  will  be 
represented  in  the  organization  servers. 

■  The  GFMIEDM  is  used  to  provide  common  semantics  and  rules  for  documentation. 

Uniquely  identifying  each  force  structure  element  in  the  GFMIEDM  across  the  GIG  is  the  second 
element.  All  force  structure  data  within  the  GFMIEDM  is  uniquely  tagged  with  Force 
Management  Identifiers  (FMIDS).  This  unique  identification  provides  the  DoD  components  the 
ability  to  manage  and  have  greater  visibility  for  any  war  fighting  or  administrative  structure,  from 
an  individual  to  a  joint  task  force  for  a  Combatant  Command.  It  allows  data  to  be  easily 
associated  and  linked  to  meet  real-time  and  unanticipated  requirements. 

All  force  structure  data  (organizations,  manpower  and  equipment  authorizations)  within  the 
organization  servers  are  tagged  and  permanently  associated  with  the  data  it  identifies.  The  intent 
is  to  share  this  data  within  and  across  the  Warfighting,  Business,  and  Intelligence  Mission  Areas, 
including  administrative  and  operational,  permanent  and  temporary  data  items. 

The  FMIDS  data  tag  will  be  retained  by  the  systems  that  use  force  structure  data  and  will  be 
assigned  to  all  existing  and  future  GFM  process  data  that  will  be  shared  across  the  Mission  Areas. 
Inherent  in  the  FMIDS  design  is  its  ability  to  enable  data  sharing  throughout  DoD,  with 
consideration  for  tactical-level  communication  systems. 

Disseminating  the  force  structure  information  in  a  net-centric  environment  is  the  third  element.  In 
addition  to  uniquely  identifying  force  structure  data,  each  organization  server,  regardless  of  the 
U.S.C.  Title  Authority,  uses  the  same  Extensible  Markup  Language  (XML)  schema.  The  use  of 
FMIDS  in  the  XML  will  be  detailed  in  the  DoD  Instructions  for  the  GFM  FSC.  The  GFMIEDM 
XML  has  one  consistent  schema,  as  approved  by  the  GFM  COI.  Net-centric  tools  will  provide  the 
functionality,  and  FMIDS  will  provide  the  means  to  link  and  integrate  data. 

6.  Development  of  a  Prototype  Is  Instrumental  to  the  GFM  COI 

One  cannot  overstate  the  importance  of  developing  a  prototype.  Many  concepts  appear  clear  in 
the  generic,  but  as  soon  as  details  are  introduced,  contradictions  seem  to  arise,  and  suddenly  basic 
assumptions  come  under  question  and  require  clearer  definitions.  The  modeling  process 
epitomizes  this  problem. 

Recall  that  the  objective  for  GFM  DI  is  to  establish  a  transparent  and  universal  process  to  manage, 
assess,  and  display  the  world-wide  disposition  of  US  forces,  including  availability,  readiness,  and 
capability,  that  enables  insight  into  global  availability  of  US  forces.  To  have  this  insight,  it  is  first 
necessary  to  have  the  force  structure  (organizational  hierarchy)  data  that  can  support  all  of  the 
automation  systems  and  have  the  flexibility  to  adapt  for  any  operational  warfighting  use.  To 
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enable  this,  GFM  DI  uses  the  “authorized”  force  structure  as  the  central  integrating  theme  for  the 
DoD.  Using  the  GFM  FSC  and  implementing  it  via  the  GFMIEDM  requires  that  three  tasks  must 
be  accomplished: 

■  The  authorized  force  structure  must  be  formally  documented  electronically  for  easy 
manipulation  within  a  computer.  This  requires  the  development  and  implementation  of 
joint,  hierarchical  force  structure  data  for  integration  across  Service  lines.  It  is  also 
necessary  to  rigorously  and  unambiguously  specify  the  semantics  and  formats  so  that 
sophisticated  computer  programs  can  economically  exploit  it. 

■  Each  piece  of  force  structure  data  must  be  uniquely  identified  for  computer  usage. 

■  The  data  must  be  capable  of  dissemination  in  accordance  with  the  DoD  Net-centric  Data 
Strategy,  with  a  minimal  amount  of  translation  required  by  any  end-users  that  requires  the 
data. 

It  is  important  to  remember  that  the  primary  goal  of  the  COI  was  the  creation  of  a  process  to 
create  reliable  and  maintainable  data.  Defining  how  the  organization  servers  would  be  populated 
with  authorization  data  was  selected  as  first  priority.  A  set  of  prototype  organization  servers  are 
being  developed  that  contain  a  typical  operational  slice  (task  organized  force)  from  each  of  the 
Services.  This  will  clarify  the  vision  of  organization  servers,  assist  in  the  evaluation  of  the 
underlying  force  structure  concept,  and  identify  subtle  problem  areas.  Working  with  the  Services, 
the  following  four  operational  slices  were  selected: 

■  An  Expeditionary  Strike  Group  (ESG)  of  the  US  Navy, 

■  A  Marine  Expeditionary  Unit  (MEU)  of  the  USMC, 

■  A  Brigade  Combat  Team  (BCT)  of  the  US  Army,  and 

■  A  Provisional  Wing  of  the  USAF. 

The  development  of  these  slices  provides  a  forum  to  interact  with  each  Service  to  identify 
concrete  issues  of  a  detailed  nature.  This,  in  turn,  provides  precise  examples  for  evaluation  and 
comparison  that  may  impact  the  development  of  general  principles  applicable  across  the  Services. 

Recall  that  an  organization  server  contains  default  authorization  data  with  the  intent  that,  when 
populated  carefully,  it  will  provide  a  set  of  default  organizations,  down  to  the  billet  level,  that 
serve  as  building  blocks  for  the  creation  of  arbitrary  orders  of  battle.  It  may  appear  ironic  (or 
confusing)  that  operational  slices  are  selected  for  demonstration,  when  what  is  actually  being 
created  is  the  default  subset  of  the  Service  Organization  Server  required  to  build  the  operational 
slice.  However,  this  is  exactly  how  the  concept  is  implemented.  The  operational  slices  are  task- 
organized  forces  created  from  the  force  structure  data  within  the  Service  Organization  Servers. 
The  selection  of  the  operational  slice  allows  the  minimal  subset  of  default  organizations  to  be 
identified,  thus  making  the  task  of  building  a  prototype  tractable.15  In  addition,  a  portion  of  the 
“top”  few  echelons  of  the  Services  are  created  to  provide  a  continuous  default  structure  down  to 


15 


This  approach  was  selected  because  the  alternative  would  have  been  to  build  the  entire  Service  structure,  which 
was  far  beyond  the  capability  of  the  COL 


10 


the  subordinate  organizations  being  used  for  the  operational  slice.  Thus,  the  top  node  in  each  of 
the  Service  Organization  Servers  is  their  department  (e.g.,  Department  of  the  Air  Force). 

A  detailed  discussion  of  the  second  task,  unique  identification,  is  not  included  in  this  paper 
because  it  has  been  described  in  detail  in  past  Command  &  Control  Research  &  Technology 
Symposium  papers.16  Current  plans  are  to  use  a  common  identification  scheme,  the  set  of  which 
are  called  FMIDS,  that  implement  the  data  type  and  procedures  described  in  the  referenced  paper. 
This  data  type  is  currently  named  an  Enterprise-wide  Identifier  (EwID)  and  is  a  64-bit  non- 
intelligent  number.  Ultimately,  as  bandwidth  becomes  available  at  the  lowest  (fighting)  echelons, 
existing  FMIDS  will  be  converted  to  Version  3  (name  based)  UUIDs  (Universally  Unique 
Identifier),17  while  new  FMIDS  can  be  created  using  any  of  the  UUID  types. 

The  third  task,  dissemination,  requires  that  an  interface  specification  be  developed.  There  are 
many  ways  to  accomplish  this  task,  and  all  require  that  significant  time  and  intellectual  effort  be 
expended  to  carefully  and  rigorously  define  the  required  properties  and  semantics  of  the  data. 
Two  criteria  agreed  to  by  the  COI  were:  one,  to  take  full  advantage  of  the  plethora  of  work 
already  done  in  this  area,  and  two,  to  try  to  address  Allied  interoperability  in  concert  with  its  joint 
counterpart.  This  second  criterion  was  based  in  part  on  the  concept  that  joint  and  Service  battle 
command  requirements  are  actually  super  sets  of  the  multinational  core  requirements.18  For  these 
reasons,  an  information  exchange  data  model  (IEDM)  developed  under  the  MIP  was  chosen  as  the 
starting  point  for  the  GFM  DI  interface  specification.  IEDM’s  are  one  method  for  defining 
information  exchange  specifications  and  offer  extensive  features  for  defining  detailed  semantics. 
More  important,  the  MIP  JC3IEDM  has  been  under  development  for  years  and  has  been  adopted 
and  implemented  in  several  NATO  battle  command  systems. 

As  stated  previously,  the  GFMIEDM  is  an  augmented  subset  of  the  JC3IEDM.  Whenever 
possible,  the  JC3IEDM  values  are  used.  A  major  tenet  is  to  keep  the  specification  to  a  minimal 
size.  To  date,  the  GFMIEDM  contains  46  entities  of  which  7  are  new,  most  notably  to  support 
manpower  authorization  requirements.  When  new  items  are  added,  care  is  taken  not  to  duplicate 
JC3IEDM  resources  and  to  consider  how  the  new  values  would  be  mapped  into  the  JC3IEDM 
attributes. 

COIs  and  XML  are  no  panacea.  Even  though  discovery  mechanisms  and  meta-data  tags  are 
included  via  the  NCDS,  there  are  still  a  myriad  of  opportunities  to  create  and  interpret  force 
structure  data  in  many  different  contexts.  Perhaps  this  is  the  most  difficult  challenge  of  the  COI: 
to  develop  a  force  structure  construct  rigorous  enough  so  that  applications  can  share  data  and 
interpret  the  resulting  information  uniformly.  Without  a  prototype  to  expose  subtle  differences, 
this  task  could  not  be  accomplished.  Terms  like  “assign,”  “attach,”  and  “operational  control”  have 
English  definitions,  but  when  one  begins  to  explore  their  use  across  the  Services  and  echelons, 
ambiguities  arise  that  can  be  surprising.  These  definitions  must  be  clearly  defined  by  the  COI 
membership. 


16  See:  Implementation  of  an  Enterprise  Identifier  Seed  Server  for  Joint  and  Coalition  Systems,  7th  ICCRTS  at 
http://www.dodccrp.org/html/events  0102.html  or  http://www.arl.armv.mil/~wildman/PAPERS/7thc2rt.html. 

17  UUID:  From  the  ISO-1 1578  (Remote  Procedure  Call,  RPC)  standard  that  is  based  upon  The  Open  Group 
Distributed  Computing  Environment  (DCE)  RPC  standard. 

18  See  CCRP  Paper  Multinational  Interoperability  Requirements  —A  Core  Competency  from  the  5th  ICCRTS, 
http://www.dodccrp.org/events/2000/5th  ICCRTS/cd/papers/Track3/0 1 0.pdf. 
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The  Service  Organization  Server  interfaces  may  provide  as  many  features  (e.g.,  web  services)  as 
desired  by  their  maintainers,  but  the  minimum  requirement  is  to  be  able  to  delivery  organization 
server  data  in  an  XMLized  GFMIEDM  format.  It  is  important  to  understand  that  the  GFMIEDM 
is  an  information  exchange  standard  and  does  not  dictate  how  the  data  is  physically  stored  within 
an  organization  server.  The  internal  design  of  the  organization  server  is  left  to  the  discretion  of 
the  owners.  However,  this  does  not  detract  from  the  rigor  required  in  the  design,  implementation, 
and  adherence  to  the  GFMIEDM. 

7.  Summary 

This  paper  described  a  few  of  the  challenges  and  discoveries  associated  with  the  establishment  of 
a  Community  of  Interest  to  provide  solutions  to  information  problems  associated  with  the  Global 
Force  Management  Data  Initiative  task.  The  GFM  COI  has  evolved  considerably  since  its 
inception  on  11  July  2003.  Not  surprisingly,  a  COI  is  no  panacea;  and  it  does  not  displace  the 
difficult  task  and  extensive  intellectual  efforts  required  to  establish  agreements  among  diverse 
users  of  data,  even  when  the  data  set  is  restricted.  Reflecting  back  on  its  short  history,  the 
realization  of  several  prominent  characteristics  seems  to  have  facilitated  moderate  success  to  date. 

a.  A  Community  of  Interest  (COI}  Should  Be  Created^  To  Solve  A  Problem.  The  GFM  COI 
was  established  to  address  a  real,  concrete  problem.  This  may  appear  to  be  an  obvious  criterion, 
but  it  is  tempting  to  establish  a  COI  for  a  general  domain  or  problem  area  without  identifying  a 
particular  problem  on  which  to  work.  Throughout  its  existence,  a  significant  portion  of  the  effort 
of  the  COI  has  been  the  continual  development  and  refinement  of  a  rigorous  definition  of  the 
GFM  DI  problem. 

b.  The  GFM  DI 's  Scope  Is  Enterprise  Wide ,  Making  It  A  Special  Challenge  For  A  COI.  The 
GFM  DI  realm,  or  more  specifically,  organization  and  force  structure  information,  crosses  every 
mission  area  and  domain  in  the  DoD.  A  primary  purpose  stated  for  creating  COIs,  per  the  NCDS, 
is  that,  “Moving  these  responsibilities  to  a  COI  level  reduces  the  coordination  effort  as  compared 
to  managing  every  data  element  Department-wide.”  Unfortunately,  by  its  nature,  the  majority  of 
data  associated  with  the  GFM  realm  is  inherently  Department-wide,  thus  the  COI  concept  did  not 
attenuate  this  challenge.  However,  by  continually  defining  the  GFM  domain,  the  COI  is  able  to 
restrict  the  focus  of  the  group  to  major  issues,  thus  reducing  distractions  from  less  immediate 
problems.  Because  of  the  enterprise-wide  nature  of  the  GFM  DI  objectives,  significant  assistance 
and  participation  from  senior  DoD  leadership  was  sought  and  obtained.  The  Joint  Staff  Director, 
J-8  and  his  senior  staff  continue  to  be  major  participants  in  securing  cooperation  from  and 
establishing  policy  with  the  Services,  Joint  Staff,  and  other  DoD  agencies.  Simply  stated,  the 
success  of  this  COI  is  dependent  on  the  participation  of  the  Services.  Without  the  emphasis 
placed  by  senior  leadership,  the  GFM  COI  would  not  have  achieved  the  successes  it  has. 

c.  CO/  Representatives  Fluctuate  As  The  Solution  Evolves .  COI  membership  requirements 
fluctuate  with  the  problem  set  or  phase  being  addressed.  One  should  not  expect  to  have  a  static  set 
of  COI  representatives.  Although  an  attempt  is  made  to  maintain  a  stable  group  of  leaders  from 
the  participating  agencies,  one  of  the  most  challenging  tasks  is  to  bring  the  right  set  of  experts 
together  as  the  meetings  are  assembled.  This  means  that  meeting  agendas  have  to  be  carefully 
considered  and  published  well  in  advance,  with  specific  topics  prepared  and  exit  criteria  defined. 
One  of  the  most  time  consuming  facets  of  a  COI  is  educating  its  membership.  Consequently, 
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there  is  a  constant  effort  to  achieve  a  balance  between  maintaining  a  stable  membership  and 
acquiring  the  right  expertise.  To  be  successful,  significant  time  must  be  allocated  to  educating 
new  and  transient  members. 

d.  Vision  Without  Funding  Is  Hallucination.  The  dedication  and  hard  work  of  a  COI 
membership  will  only  lead  to  success  if  funding  is  provided  to  implement  its  results.  For  this 
reason,  the  COI  leadership  also  participated  in  the  Enhanced  Planning  Process  to  ensure  that  the 
Services  were  funded  when  required.  This  included  both  securing  “seed”  funding  for  the  initiation 
of  the  Service  organization  servers  and  ensuring  that  the  Services  budgeted  for  their  care  and 
maintenance  in  future  years. 

e.  A  CO]_  Requires  a  Set  of  Guiding  Principles  and  Tenets.  It  is  essential  to  specify  a  set  of 
principles  and  tenets  to  guide  the  COI  data  development  process.  For  example,  the  primary  goal 
of  the  GFM  COI  is  not  merely  the  specification  of  data  and  services,  but  the  actual  creation  and 
maintenance  of  the  data  in  an  unambiguous  form.  Paramount  to  this  objective  is  the  identification 
and  sanctioning  of  authoritative  data  sources.  No  other  task  of  the  COI  has  been  more  challenging 
that  this  one,  particularly  because  it  is  not  one  of  time  obligation,  but  requires  a  continuing 
commitment  to  provide  highly  detailed,  quality  data  to  the  DoD,  and  ultimately,  to  our  Allied 
partners.  Further,  the  principles  must  apply  to  both  technical  strategies  and  policies  so  that 
informed  decisions  can  be  made  to  compromise  when  necessary,  but  still  maintain  enough 
constraints  to  ensure  the  solutions  converge  to  a  workable  and  interoperable  end  state. 

f.  Development  of  a  Prototype  Is  Instrumental-  To  evaluate  the  principles,  policies,  and 
technical  strategies  accepted  by  the  GFM  COI,  the  development  of  a  prototype  remains 
instrumental  in  producing  a  realistic,  workable,  and  minimal  solution  to  a  very  difficult  set  of 
criteria.  The  importance  of  the  GFM  DI  cannot  be  overstated.  Actual  force  structure  slices  of  the 
four  Services  are  being  created  to  identify  problems  and  ambiguities  in  the  data  and  operational 
definitions  that  could  otherwise  easily  go  undiscovered.  The  results  of  the  prototype  provide 
concrete  examples  that  make  it  possible  for  the  COI  members  to  assimilate  the  general  problems 
and  provide  explicit  solutions  to  subtly  difficult  concepts  that  have  been  taken  for  granted  for 
years  because  they  have  been  hidden  within  their  English  definitions.  It  is  a  difficult  task  to  create 
rigorous  and  formal  definitions  of  military  operational  concepts  so  that  they  can  be  “understood” 
by  computer  algorithms.  Perhaps  this  daunting  task  was  best  reiterated  by  Gen  Bruce  C.  Clarke 
who  often  repeated  a  statement  by  one  of  his  English  professors:  “If  you're  going  to  be  successful 
in  the  military  where  you  have  to  issue  instructions  and  orders,  you  must  have  the  ability  to  issue 
them,  not  just  to  be  understood,  but  so  you  can't  be  misunderstood.”19 


19  See:  http://www.trumanlibrary.org/oralhist/cIarkeb.htm. 
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A  Community  of  Interest  (COI) 
Should  Be  Created  To  Solve  A  Problem 


Data  is  not  visible, 
accessible  or  usable 


Process  is  not  integrated 


GFM  Data  Needs 

Force  Structure  Data 
-Current  Unit  Locations 
-“Event”  data 
-Operational  Availability 
-Total  US  Inventory 
-Joint  hierarchically 
organized 

Historical  archive 
Timely,  reliable,  and 
authoritative 


Directives 

1.  Per  SecDef’s  Memo,  JS  to  integrate  assignment,  allocation  and  apportionment  processes 

2.  Per  SROC  Guidance,  the  JS  will  implement  enterprise-wide  unit  identifiers 

3.  Per  SPG  FY06-11,  CJCS  to  develop/organize  force  structure  data  across  Service  lines 

4.  Per  JPG  DepSecDef  Memo,  USN,  USAF,  USMC  add  $  during  FY  2006-2011  for  development  of 
standardized  force  structure  data  to  provide  on-demand  information  in  a  net-centric  environment 
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COI  Representatives  Fluctuate  As  The  Solution  Evolves 
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•  Hardcore  computer 
science  problem 

-No  “silver  bullet” 

-  Must  create  the  data 

•  Must  document  all 
organizations 

-Administrative 

-Combatant 

-Operational 

-  Rigorously  reported 

-Starting  point  for  any 
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•  Disseminate  from  a 
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Vision  Without  Funding  Is  Hallucination  (GFM  EPP  Tasks) 


■  ■■I 


•  Task  1:  Joint  Staff,  J-8  identifies  required  GFM  data  elements 
(unit,  location,  event,  ...)  to  include  Defense  readiness  Reporting 
System  (DRRS)  data  elements  NLT  2  Feb  04 

•  Task  2:  Components  identify  all  GFM  authoritative  sources 
(databases)  to  match  the  data  model  resulting  from  Task  1 
NLT  17  Feb  04 

•  Task  3:  Components  will  identify  and  develop  roadmaps  on  when 
these  GFM  authoritative  sources  will  be  created  and  web-service- 
enabled  NLT  1  Mar  04 

•  Task  4:  Joint  Staff  and  GFM  Enhanced  Planning  Process  (EPP)  Issue 
Team  will  evaluate  the  roadmaps  to  web-service-enabled  GFM 
authoritative  sources  to  achieve  desired  capabilities  NLT  1  Apr  04 

•  Task  5:  Joint  Staff  and  GFM  EPP  Issue  Team  develop  draft 
Joint  Programming  Guidance  (JPG)  language  NLT  15  Apr  04 

•  Task  6:  Components  review  draft  JPG  language  NLT  1  May  04 
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A  COI  Requires  a  Set  of  Guiding  Principles  and  Tenets 
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-  Documented  in  an  single  authoritative  data  source  call  the 
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Development  of  a  Prototype  Is  Instrumental  [1] 

*  Preparing  a  “Combat  Slice”  from  each  of  the  Services 
and  putting  it  into  GFMIEDM  format 

-  Navy  -  2nd  Expeditionary  Strike  Group  (ESG) 

-  USMC  -  26th  Marine  Expeditionary  Unit  (MEU) 

-  Army  -  1st  Brigade  Combat  Team,  1st  Cavalry  Division 

-  Air  Force  -  4404th  Wing  (Provisional)  -  AEW 

•  Simultaneously  preparing  the  Concept  of  the 
Operations  (CONOPS)  in  three  areas: 

-  Organization  Server  Operations 

-  Allocation,  Assignment  &  Apportionment  process 

-  GFM  in  a  net-centric  environment 


t  > 

Objectives:  Define  business  rules,  flush  out  GFMIEDM, 
and  demonstrate  capabilities  of  GFM  Dl  prototype 
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Development  of  a  Prototype  Is  Instrumental  [2] 
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Development  of  a  Prototype  Is  Instrumental  [3] 
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Development  of  a  Prototype  Is  Instrumental  [4] 


II 


Organization  Chart  Demo:  dtv3chart3  @  2005-03-28  Mike  =  01000244 
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Development  of  a  Prototype  Is  Instrumental  [5] 
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Summary 
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a.  A  Community  of  Interest  (COI)  Should  Be  Created 
To  Solve  A  Problem. 

b.  The  Global  Force  Management  Data  Initiative’s  (GFM  Dl) 
Scope  Is  Enterprise  Wide ,  Making  It  A  Special  Challenge 
For  A  COI. 

c.  COI  Representatives  Fluctuate  As  The  Solution  Evolves 

d.  Vision  Without  Funding  Is  Hallucination 

e.  A  COI  Requires  a  Set  of  Guiding  Principles  and  Tenets 

f.  Development  of  a  Prototype  Is  Instrumental 
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